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Abstract 

Object oriented constraint programs (OOCPs) emerge as a leading evolution 
of constraint programming and artificial intelligence, first applied to a range of 
industrial applications called configuration problems. The rich variety of tech- 
nical approaches to solving configuration problems (CLP(FD), CC(FD), DCSP, 
Terminological systems, constraint programs with set variables, . . . ) is a source 
of difficulty. No universally accepted formal language exists for communicating 
about OOCPs, which makes the comparison of systems difficult. We present here 
a Z based specification of OOCPs which avoids the falltrap of hidden object se- 
mantics. The object system is part of the specification, and captures all of the most 
advanced notions from the object oriented modeling standard UML. The paper il- 
lustrates these issues and the conciseness and precision of Z by the specification 
of a working OOCP that solves an historical AI problem : parsing a context free 
grammar. Being written in Z, an OOCP specification also supports formal proofs. 
The whole builds the foundation of an adaptative and evolving framework for com- 
municating about constrained object models and programs. 



Introduction 

From Configuration to Object Oriented Constraint Programs 

Rule based systems, logic programming, and a recent evolution of constraint program- 
ming have been applied to a category of problems called configuration problems. Con- 
figuring means simulating the construction of a composite and complex product, based 
on a library of elementary components. Components are subject to relations (this is the 
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partonomic information), and participate to inheritance relationships (this is called the 
taxonomic information). Given an input in the form of a partial product and specific 
constraints, the goal of configuration is to pick up or generate, then interconnect the 
necessary components, for finally deciding upon their exact type and attribute values. 
Configuration output is a complex interconnected product respecting well formedness 
rules stated by various constraints. This combinatorial problem is explicitly formulated 
as a finite model generation problem. 
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Figure 1: A simplified object model for a personal computer 



The figure n illustrates this with a classical example. Configuring a personal com- 
puter (PC) consists in picking components from a catalog of component parts (e.g. 
processors, hard disks in a PC ), using known relations between types (motherboards 
can connect up to four processors), and instantiating object attributes (selecting the 
ram size, bus speed, . . . ). Constraints apply to such configuration problems that define 
which products are valid, or well formed. For example in a PC, the processors on a 
motherboard all have the same type, the ram units have the same wait times, the total 
power of a power supply must exceed the total power demand of all the devices. Con- 
figuration applications deal with such constraints, that bind variables occurring in the 
form of variable object attributes deep within the object structure. 

We suggest to abandon the term configuration, bound to a very specific applica- 
tion area (even if it is broadly distributed in the economy), in favor of a more general 
purpose and AI related denomination : object oriented constraint programs (OOCP for 
short). OOCP has many potential AI applications, ranging from context free language 
parsing (we use this example), to image recognition, or distributed agent intelligence 
and planning. 
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Existing approaches 

The industrial need for configuration is widespread, and has triggered the development 
of many applications, as well as generic configuration tools or configurators, built upon 
all available technologies. For instance, configuration is a leading application field 
for rule based expert systems. As an evolution of R1 II17I . the XCON system Q de- 
signed in 1989 for computer configuration at Digital Equipment involved 31000 com- 
ponents, and 17000 rules. The application of configuration is experimented or planned 
in many different industrial fields, electronic commerce (the CAWICOMS proiect llOl '). 
software [29], computers f2Tl, electric engine power supplies fTS'l and many others like 
vehicles, electronic devices, customer relation management (CRM) or even software t29l 

El. 

The high variability rate of configuration knowledge (parts catalogs may vary by 
up to a third each year) makes configuration application maintenance a challenging 
task. Rule based systems like Rl or XCON lack modularity in that respect, which 
encouraged researchers to use variants of the CSP formalism (like DCSP ri8"24''2|, 
structural CSP [I9j, composite CSP |22|), constraint logic programming (CLP 1 14l . 
CC II II . stable model semantics for logic programs with disjunctions 1251 1. or object 
oriented approaches 1*271 l28l 1 1 61 1201 . 

Because of the variety of approaches to this problem (CLP(FD), CC(FD), CP and 
extensions. Expert Systems), no common language is available for researchers to ex- 
change problem statements and compare their results. Each of the above cited articles 
uses an ad-hoc description of its working example. Some UML| 12 1 models are pre- 
sented from time to time, which never allow to overcome the ambiguities inherent to 
this exercise, even though the UML is far more formal than people usually think. The 
objective of this paper is to propose to this growing community a common language 
for exchanging models and problems. 

Paper objectives 

This paper presents a general use object oriented constraint system for the specification 
of object oriented constraint problems. The object system is not predefined, or provided 
as an object oriented extension to some specification language. Instead, we have chosen 
to make the object system specification explicit, using the Z language 1261 . There are 
several reasons for both the choice of Z and this approach: 

• we feel that in order to be widely accepted, the underlying semantic of an object 
system must be questionable, commented, improved, and formally established, 

• the Z language has very simple and clear semantics, and offers an extremely 
rich range of relational operations, a crucial issue in object oriented constraint 
programming, 

• the Z language was shown to have the favor of the industry over other speci- 
fication language^!, essentially because of its structure (the grouping concept 
introduced by schemas) 
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• we have succeeded in specifying in Z the most advanced class modeling con- 
structs from the UML|12|, which has become the standard in object oriented 
modeling. This guarantees that modeling cannot be biased, or tweaked by arbi- 
trary limitations in the object language, and that any object oriented model can 
be specified 

• Z specifications can be type checked (we used /uzz' extensively to type check 
this paper), which offers a first level of formal verification, 

• Z specifications are subject to formal proofs, possibly assisted or automatized by 
theorem provers, 

• Z offers built in extensibility features, that allow to formally define, then use, any 
operator or relation using any possible syntax (prefix, infix, postfix). We exploit 
this feature to improve the readability of constraints. 

To summarize this, we found that Z is the simplest logic offering both structure (via 
schemas) and support for the formal definition of complex structural constraints or 
expressions. This last issue is crucial to object oriented constraint programs, for in- 
stance to allow the statement of a constraint relating, in a personal computer, the sum 
of powers used by all elementary electrical devices, and the power made available by 
the supply. It was furthermore argued| 13 1 that coalgebras support most of the notions 
required to deal with object state and class invariants. Relational algebraic languages 
like Z provide the capacity of specifying both algebras (types and their operations) and 
coalgebras (states and their transitions). 

There have been many attempts to capture object orientation within specification 
languages, either viewed as Z extensions (Object Z|23 1, OOZE| 1 1) or based upon other 
mathematical grounds (the FOOPS|6| extension to OBJ). A logical approach to object 
orientation is also put to work in terminological knowledge representation languages | 7| 
|3l)- Also, constraint programming has been introduced in object oriented knowledge 
representation languages (as e.g in CLAIRE|8|). 

We are not presenting the latest object oriented language, or system, or extension to 
whichever existing approach. Our aim is to capture rich enough object oriented seman- 
tics in a simple and unmodified logic (hence Z), rather than to rely upon the inherent 
semantics of an object oriented extension of some logic. By doing so, we prevent both 
the potential expressiveness limitations of any given object system, and the possibility 
that its semantics are improperly defined, or questionable. Our approach allows to doc- 
ument an object oriented constraint program, by simultaneously specifying both the 
object system semantics, and the problem itself. This task is made simpler because we 
do not need to specify state transitions (coalgebra operations), but reason exclusively 
about state. Essential issues in object oriented programming like polymorphism, or 
concurrency are irrelevant here. Our goal is to express valid object system states, us- 
ing constraints, which altogether describe an object oriented constraint program. This 
simplifies the use we make of Z, because in our case decorations are useless. 

The paper is organized as follows : section 1 briefly introduces essential aspects of 
Z. Section 2 specifies the class and type features of an object system, illustrating how 

'available at |http://spivey.oriel.ox.ac.uk~niike/fuzz/| 
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all essential object oriented modeling concepts can be captured. Section 3 specifies re- 
lations and roles. Section 4 details how object structure constraints can be formulated, 
and introduces useful auxiliary constructs. Section 5 presents the specification of an 
artificial intelligence application of object oriented constraint programs to context free 
grammars parsing. Section 6 is the conclusion. It can be a possible reading strategy to 
first take a glance at section 5, since it illustrates the essential motivation of this work. 

1 Introducing Z 

For space reasons, it is impossible to make this paper self contained, since this would 
suppose a thorough presentation of both the UML notation! 12|, and the Z specification 
language 1 26 1 . The reader, if novice in these domains, is kindly expected to make his 
way through the documentation, which is electronically available. For clarity however, 
we provide a brief description of several useful Z constructs. More advanced notations 
or concepts will be introduced when necessary. 

1.1 data types as named sets 

Z data types are possibly infinite sets, either uninterpreted, defined axiomatically, or 
defined as (possibly recursive) free types as the next three examples illustrate. 

[DATE] 

I dom : F N 

colors ::— red \ green \ blue 
From this on, all possible relation types can be built from cross products of other sets. 

1.2 axiomatic definitions 

Axiomatic definitions allow to define global symbols having plain or relation types. 
For instance, a finite group is declared as 

zero : dom 

inverse : dom — > dom 
sum : dom x dom — > dom 

Vx : dom • sum{x, inverse{x)) ~ zero 

Vx : dom • sum(x, zero) = x 

y x,y : dom • sum(x,y) = sum(y,x) 

yx,y,z : dom • sum{x,sum{y,z)) — sut7i{sum{x,y),z) 

The previous axiomatic definition illustrates cross products and function definitions 
as means of typing Z elements. Now axioms or theorems are expressed in classical 
math style, involving previously defined sets. For instance, we may formulate that the 
inverse function above is bijective (this is a theorem) in several equivalent ways as e.g.: 

inverse G dom dom 

Vy : dom • jc : dom • inverse (x) = y 
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1.3 schemas 

The most important Z construct, schemas, occur in the specification in the form of 
named axiomatic definitions. A schema [D \ P] combines one or several variable decla- 
rations (in the declaration part D) together with a predicate P stating validity conditions 
(or constraints) that apply to the declared variables. 

Schema One 

a : N 

b:1..10 

b < a 



The schema name hides the inner declarations, which are not global. A schema name 
(as SchemaOne above) is used as a shortcut for its variable and predicate declarations 
that can be universally or existentially quantified at will. Schemas are true or false 
under a given binding. For instance, SchemaOne is true under the binding (4^a, i^b) 

false under the bindings (3 ^ a, 234 ^ fe) or (3 ^ a, 4 ^ b). The latter violates 
the explicit constraint stated in the predicate part of the schema, while the former also 
violates the implicit constraint carried by the interval definition 1 . . 10 (a subset of N). 
In some contexts, a schema name denotes the set of bindings under which it is true. 

Z allows Boolean schema composition. Two schemas can be logically combined 
(e.g. "anded") by merging their declaration parts provided no conflict arises between 
the types of similarly called variables, and by applying the corresponding logical opera- 
tor (e.g. the conjunction) to the predicates. For instance, given the schema SchemaOne 
above, and another schema called SchemaTwo ^ [b : N; c : N \ b < c] (this il- 
lustrates another syntax for simple schema declarations), we may form the schema 
SchemaThree, as 

SchemaThree = SchemaOne A SchemaTwo 

Incidentally, the variable declarations b in both schemas collide, but not for their types 
since b is a member of N in both cases. The first declaration of b bears a built in 
constraint, which can be moved to the predicate part. Hence the schema SchemaThree 
would list as : 

SchemaThree 

a,b,c : N 

Kb <10 
b < a 
b < c 



2 Classes 

We wish to describe Z specified object oriented constructs so as to reach an expressive 
power comparable to that allowed by the UML I12I class (and state) diagrams, hence 
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allowing to model in a purely formal way the static properties of an object constraint 
system. In order to sit our definitions on clean formal grounds, we propose a generic 
Z specification that captures all required concepts. In defining classes, we specially 
need to cover two essential notions : multiple inheritance and multiple discriminator 
speciahzation. While the former is attained by existing object oriented Z extensions, 
the latter is not, which partly justifies this work. An essential contribution of this work 
is that the object system specification is explicit, and can be discussed, adapted, or 
extended at will. Essential in this respect is the clarity and soundness of the notion of 
"object references", made explicit here. 

The schema notation can be understood as an heterogeneous aggregate of mathe- 
matical variables, subject to built in constraints. In other words, schemas can be seen 
as mathematical variables representing all the possible states of Pascal records, or of C 
structs. From an object oriented point of view, the predicate part of a schema forms the 
essence of what is called in OO programming a class invariant : a property that must 
be true of object instances at all times (i.e. before and after any method call). 

2.1 preliminary definitions 

The object oriented vocabulary involves common and rather vague words. We wish 
to make things precise, and to avoid difficulties in the sequel. A class definition holds 
the description of class specific attributes and class specific invariant together with 
inheritance relationships. Accounting for inheritance yields a description of the (fiill) 
class structure and (full) class invariant which together form the class specification. 
A class instance, or object is a binding of values to all attributes in the class structure 
that satisfies the class invariant. Such a binding is sometimes referred to as state. The 
set of all object instances bijectively maps to a set of object references. The bijection 
between object references and class instances allows for a precise definition of class 
and type. We call class the set of object references mapped to all the instances of a 
given class structure. A type recursively defines as the union of a given class, and of 
all its subclass types down the inheritance directed acyclic graph. By defining types as 
sets, we stay respectful of Z's terminology, which identifies sets and types. All these 
definitions will be illustrated and made understandable by examples in the sequel. Z 
provides enough constructs to account for classification mechanisms. We first define a 
set ObjectReference of object references as an uninterpreted data type. 

[ObjectReference] 

ObjectReference would be interpreted on the set of natural numbers (or a finite subset) 
by an automated theorem proving approach based on finite model generation. Practical 
implementations of object systems typically use pointers or integers as object refer- 
ences. We define ReferenceSet as an abbreviation for finite sets of object references, 
later used to model object types. 

ReferenceSet == F ObjectReference 

We define class names as global names using Z's free type declaration syntax. For 
practical reasons, if a class should have the name Engine, we reserve the symbol Engine 
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to denote the corresponding type. The global symbol denoting the class definition is 
obtained by prepending the string "Class" to the actual name. In our example, the class 
name thus writes as ClassEngine. Depending upon the context, the declaration of class 
names may look Uke : 

CLASSNAME ::= ClassPC \ ClassPrinter \ ClassMonitor \ ... 
CLASSNAME ::= ClassCar \ ClassWheel \ ClassEngine \ ... 

We now declare ObjectDef as a predefined super class for all future classes. Object 
definitions will be used to bijectively map each object to a unique individual from the 
set ObjectReference. Object references are needed in addition to object state since 
in object oriented modeUng two distinct objects may share the same attribute values 
(whereas in Z two "bitwise equal" bindings represent the same logical entity). Also, 
since two distinct Z schemas may have the same Z type, we need to integrate the actual 
class name in objects. 

ObjectDef 

i : ObjectReference 
class : CLASSNAME 



We define a function instances mapping class names to the set of instances of that class. 

I instances : CLASSNAME — > ReferenceSet 

2.2 defining class structures using intieritance 

An essential aspect of object oriented modeling is that objects are associated with state. 
On the one hand, inheritance relations allow to restrict the possible values of attributes 
declared in superclasses (this phenomenon is called inheritance for specialization). On 
the other hand, classes may extend the list of attributes defined in superclasses by their 
own (this is called inheritance for extension). Most situations where inheritance occurs 
combine both cases in a single inheritance relation. Z offers built in representation 
of state in the form of schemas. We now show a way to associate such schemas to 
individual types in a standardized way, so as to bind state to the types as declared 
previously. We illustrate this through a simple three class example : class B inherits A, 
extending it with an extra attribute, and class C specializes A with an extra constraint. 

Each class X is implemented via two constructs. First, the class definition occurs 
as a schema called ClassDefX (we prepend "ClassDef to the desired class name to 
form the schema name). This schema defines both the class attributes and inheritance 
relationships, as would any class definition do in object oriented modeling or program- 
ming languages. The predicate part of the schema offers room for the specification of 
class invariants. 

ClassDef A 

a : 1 . . 10 
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ClassDefB 

ClassDefA 
b : Ni 



ClassDefC 

ClassDefA 

a>5 



Class definitions as seen above account for inheritance by simply copying the definition 
schemas of the inherited (super) classes. Doing so allows to state constraints involving 
attributes pertaining to super classes (this is specialization). All the predicates present 
in the inherited classes are conjoined (i.e. logically "anded") to the predicate part of the 
resulting schema. This formulation hence adequately accounts for both types of inheri- 
tance : extension and specialization. Note that the types of all inherited attributes must 
match. If attributes having the same name are inherited from two distinct superclasses, 
either or both can be renamed to prevent clashes, as e.g. in : 

ClassDefD 

ClassDejB[d/b] 

d = 5 



where the constraint d ^ 5 actually binds the attribute originally declared as b in 
ClassDeJB. A Z type checker can detect errors in the formulation of such class def- 
initions, specially when type conflicts occur for attributes having the same name. A 
potential cause of error remains if two conceptually distinct yet non distinguishable 
attributes exist in two inherited classes. 

To implement a working object system, we need to add some extra technical infor- 
mation to class definition schemas : object and class references. Like before, schema 
composition with the logical operator A offers the expected semantics of extension by 
combining the schema types of the two schemas and of specialization by conjoining 
their predicate parts. Assuming the same toy example as before, (A is a toplevel class 
that B and C inherit), we write the following : 

ClassSpecA = ClassDefA A [ObjectDef \ class = ClassA ] 
ClassSpecB = ClassDeJB A [ObjectDef \ class = ClassB ] 
ClassSpecC = ClassDefC A [ObjectDef | class = ClassC] 

It must be understood that the schema types corresponding to ClassSpecA and ClassSpecC 
are the same (this schema type is noted : ObjectReference; a : N; class : CLASSNAME) 
in Z), even though the schema names differ, because class C specializes A but does not 
extend it. Hence a specific workaround is needed to make sure that the set of bindings 
that satisfy ClassSpecC is not included in ClassSpecA, and more generally that no two 
sets of bindings satisfying two distinct class definition schemas can intersect. This goal 
is achieved thanks to the class attribute inserted via the schema ClassDef, that takes a 
distinct value for each class. 
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2.3 defining class types 

We can now make our toy ABC model more complete, and define what the types 
A, B, C represent. We use an axiomatic definition of three sets A, B, C as finite 
sets of object references: 

A,B,C : ReferenceSet 

A = instances {Class A) UB U C 

instances{ClassA) = {o : ClassSpecA \ o.class = ClassA • o.i} 

instances{ClassB) = {o : ClassSpecB \ o.class = ClassB • o.i\ 
instances{ClassC) = {o : ClassSpecC \ o.class — ClassC • o.i} 

\/i : instances (ClassA) • (3^^ x : ClassSpecA • x.i = i) 
Vj : instances{ClassB) • : ClassSpecB • x.i = i) 
Mi : instances{ClassC) • (3^x : ClassSpecC • x.i = i) 

The declaration part in this axiomatic definition declares the type sets corresponding 
to all the classes in our toy model. The properties of these sets are stated by several 
axioms : 

• The types of sub classes are subsets of a class type. A type is the union of (the 
object references of) all the corresponding class instances, and of the types of its 
subclasses. Note that by making our example more complete the types B and C 
might intersect, because of multiple inheritance. 

• The set instances{ClassX) holds the schema bindings having the "class" attribute 
set to ClassX. These sets are pairwise disjoint by construction 

• The other set, X, corresponds to the classical notion of a type. 

• The same object reference cannot be used for two distinct objects in the same 
class. 

These axioms ensure that each object reference is used at most once for an object. 
Alternatively stated, no two distinct "object" bindings share the same object reference. 
The preceding type definitions make the set ObjectReference the most general type 
in the model. Based upon these definitions, any class located in the middle of the 
inheritance tree is concrete : in an interpretation, we may have an instance of A that is 
neither an instance of B nor C. Finally, this specification makes clear the distinction 
between : 

• a class definition : this is the schema ClassDefii, which accounts for inheritance, 

• a class specification : this is ClassSpecX, which accounts for object and class 
references, 

• a class : this is represented by the set instances{ClassX), 

• an object's type : any set X to which the object's reference belongs (if an object 
is an instance of class B, and B inherits A, it is accepted to say that this object is 
a "B", and also that it is an "A"). 
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2.4 semantics, interpretations, objects 

An interpretation of a Z specification is a set of bindings with types corresponding 
to the schema types that occur in the specification. A model in the logical sense is 
an interpretation that satisfies all the axioms. An object is a binding satisfying the 
schema type and properties of some class specification schema (ClassSpecX). Note 
that such a binding may satisfy the schema types and properties of several distinct 
class specification schemas, because in Z the schema name isn't part of the schema 
type). This does no harm however, since the class attribute in class specification 
schemas sorts things apart. Note that the final axioms in the axiomatic definition of 
types (Vj : instances{ClassX) • (B^.v : ClassSpecX • x.i = i))...) constrain the 
valid interpretations so that each object reference occurs only once among the whole 
set of object bindings, which to the best of our knowledge cannot be formulated more 
concisely. 

2.5 creating objects 

Although we do not focus here on the dynamics of the object systems, but rather on 

the mathematical properties of their valid states, it is of some interest at this point 
to mention that we are modeling a system that could be specified further to model a 
practically usable application, where object instances can be created, and destroyed. 
To achieve this requires to get a hold over the global system state. This is achieved 
by placing the type definitions within a schema, instead of keeping them as global 
axiomatic definitions : 

ObjectSystemABC 

A,Z?, C : ReferenceSet 
ObjectsA : P ClassSpecA 

A = instances{ClassA) U B U C 

instances (ClassA) = {o : ClassSpecA \ o.class = ClassA • o.i} 
instances{ClassB) = {o : ClassSpecB \ o.class = ClassB • o.i} 
instances{ClassC) = {o : ClassSpecC \ o.class = ClassC • o.i} 

Vj : instances (ClassA) • (3^x : ClassSpecA •x.i = ;) 
V/ : instances{ClassB) • : ClassSpecB • x.i — i) 
y i : instances{ClassC) • : ClassSpecC • x.i = i) 



Now, the following schema defines how the system gets updated because of object 
creation : 

New A 

AObjectSystemABC 
n? : ClassSpecA 



ObjectsA' = ObjectsA U {n?} 
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Notice how we added to the schema ObjectSystemABC an attribute ObjectsA : P ClassSpecA. 
This paragraph and the associated schemas should be taken as a parenthesis since our 
goal here is just to specify the global properties of an object system. We will hence 
continue using axiomatic definitions instead of schemas for the global object system, 
which makes most descriptions lighter and easier to read, as long as we do not plan to 
model how the system state can change. 

2.6 dereferencing attributes 

An essential operation in object systems is to obtain the information held by the data 
structure pointed at by an object reference. This operation, called "dereferencing" can 
me modeled in our case on a per attribute basis. We prefix the attribute name by the 
string "get", and promote the first attribute letter to upper case to name the accessor 
("power" becomes "getPower"). Following is an example in our ABC toy problem : 

getA : A — > N 
Vj : A . 

getA{i) — {^v : {s : ClassSpecA \ s.i = / • s.a) U {s : ClassSpecC \ s.i = i • s.a} 

This definition uses Z's mu construct {fxx : T \ C • E) that yields the value of E on 
the unique x from T matching C. Again, it can be seen as a Uttle verbose, as a result 
of Z's non object orientedness. However, it is easily specified, and such definitions can 
be generated automatically from shortcut descriptions. 

2.7 making a class abstract 

Now, based on the same example, if we expect the class A to be abstract, i.e. we 
forbid an individual to be created as an A we simply need to add a constraint stating 
that instances{ClassX) is empty : instances {Class A) = {o : ClassSpecA \ class = 
ClassA • 0.1} = 0. 

2.8 unused objects 

The specification made so far accepts that elements of ObjectReference are members 
of none of the subtypes. Depending upon the situation (e.g. whether a constraint 
programming tool using the specification must try giving a type to all the elements in 
ObjectReference or not), we may force objects to belong to types. This is obtained by 
adding the axiom 

{instances{ClassA), instances{ClassB), instances{ClassC)) partition ObjectReference 

2.9 specializing across several discriminators 

An important concept in object oriented specification is the possibility to specialize a 
class across two different discriminators, each corresponding to different viewpoints 
over a class. For instance, a traditional real life example is the class Vehicle. It can 
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be specialized in one discriminator, called "energy", related to the energy used to 
power the vehicle. We may imagine the subclasses Humanipoweied), WindCpowered), 
Gas(powered) in that discriminator. Each subclass in this case brings its own data at- 
tributes : number of humans, number of sails, tank capacity. The Vehicle class can also 
be specialized across another discriminator : the element it moves on. We can imagine 
here the classes : Water, Ground, Air. Again, each of these classes may carry some 
data, in isolation from the others. In the declaration of types, it suffices to state the 
following (everything irrelevant has been removed): 

Vehicle, Human, Wind, Gas, Water, Ground, Air : ReferenceSet 

Vehicle = Human U Wind U Gas 
Vehicle = Water U Ground yj Air 

instances (ClassHu}7ian) = {o : ClassSpecHuman \ o.class = ClassHuman • o.i} . . . 
Vi : instances{ClassHuman) • (B^x : ClassSpecHuman • x.i — i) . . . 

The rule in the UML is that whenever such a multiple discriminator specialization 
occurs, the main class (here Vehicle) and all its child classes (i.e. Human, . . .Air) are 
abstract, and that any concrete class underneath must inherit at least one class from each 
discriminator. This is so because since vehicle is partitioned in two discriminators, any 
"Vehicle" must belong to some type among each discriminator. Obtaining this requires 
that each subclass inherits a class from each discriminator. The predicate stated in 
the axiomatic definition above ensure this: any object reference in a "sub" subclass 
of Vehicle must be a member of at least one set among Human, Wind, Gas, and of at 
least one set among Water, Ground, Air. Membership to those sets is acquired through 
inheritance. 

2.10 shortcut notation for class specifications 

Z being non object oriented in any way, the previous class and type declarations are 
verbose. For simplicity and readability, although not sacrificing rigor, we propose the 
following shortcut definition for classes and types, which makes use of the keywords 
class, abstract, discriminator, inherit. The syntax for this can be presented using sim- 
ple examples, which must be understood as a shortcut for the corresponding specifica- 
tions. 

class — A : abstract 

—discriminators : default 
a : N 

a < 10; 



class — B : concrete 

—inherit : A — default 
b : Ni 
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cZfl.s-.s- — C : concrete 

—inherit : A 

a > 5; 



A preprocessor can very easily parse such definitions, or take its input from an UML 

class design, so as to produce a listing identical to -what -was built step by step for the 
ABC example in the previous pages. Hence, a byproduct of these declarations is the 
declaration in the Z specification of the schemas : ObjectDef, ClassDefA, ClassSpecA, 
ClassDefB, . . ., and of the sets instances{ClassA), A, instances{ClassB), . . .. 

In the case of the Vehicle class, since it has two discriminators, we would declare 
(all irrelevant information is hidden): 

class — Vehicle : abstract 

—discriminators : powermode, element 



class — Human : abstract 

—inherit : Vehicle — powermode 



class — Ground : abstract 

—inherit : Vehicle — element 



class — Bicycle : concrete _ 

—inherit : Human \ Ground 



3 Relations 

Z provides the richest possible toolkit to define relations and reason about them. This 
feature is inherent in relational languages, where all common mathematical concepts, 
Uke functions, bags, sequences derive from relations through composition and con- 
straints. For instance, a function is a relation bound by an axiom of unicity. Also, a 
sequence is a function from a subset of natural numbers N to a given set. 

3.1 a simple example 

Having defined the structure and inheritance relations between classes, we must now 
describe their relations. Like before, we will study this through a concrete example, 
based on two classes Person and Company. 



class — Person 
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This specification defines schemas: 

ClassDefPerson = [ . . . | . . . ] 
ClassDefCompany = [ . . . | . . . ] 
ClassSpecPerson = [ . . . | . . . ] 
ClassSpecCompany = [ . . . | . . . ] 

as well as the appropriate constraints on instances{ClassPerson) , instances (ClassCompany) 
and also the type sets: 

I Person, Company : ReferenceSet 

3.2 relations and roles 

A relation is declared between types, no matter what the creation type of the objects is. 
In our example, we may think about these three relations : 

worksFor : Person <— > Company 
owns : Person <— > Company 
manages : Person <— > Company 

In standard object oriented modeling ll2l . relation names are complemented by role 
names, associated with each extremity of a class relation. Each role name names the 
target class role wrt. the particular relation. Role names must be specified by the object 
model. When not ambiguous (i.e. when only one relation binds two given classes), the 
target class name is implicitly accepted as a role name. Roles of binary relations can 
be axiomatically defined as follows : 

employees : Company — > P Person 
employer : Person — > P Company 

Vc : Company • employees{c) — {p : Person \ (p t—^ c) ^ worksFor} 
y p : Person • employer{p) ~ {c : Company | (/? i— » c) G worksFor} 

Note that the Z syntax allows more compact definitions for the roles employer and 
employees : 

employees{c) — AoTii{worksFor > {c}) 
employer{p) — ran({/)} < worksFor) 



employees{c) = worksFor"^ ^{c}^ 
employer{p) = worksFor^{p}^ 

where worksFor"'' denotes the relational inverse of worksFor, worksFor < {c} denotes 
the domain restriction of worksFor wrt. {c} (which is still a relation), domT? denotes 
the domain of R, and _(|_D is the relational image operator We may ease the pain of 
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declaring roles for all the relations in a model by generically defining the Irole and rrole 
Boolean functions as follows. 



r= [C, D] 

/,,./, : P((C ^D)x{D^P C)) 
rrole : ?{{C<-^D) x (C^PD)) 

VR : C ^D; I : D C • (R,l) e Irole ^ {V d : D • l{d) = R~\{d}\j) 
\fR: C ^D; r : C —^PD • {R,r) £ rrole <^ (Vc : C • r{c) = R({c}i) 



The previous axiomatic definition is generic, parameterized with types (this is the first 
time we use this). Now, the declaration of the roles associated to the relation worksFor 
can be simplified : 

employees : Company — > P Person 
employer : Person — > P Company 

{worksFor, employees) £ Irole 
{worksFor, employer) G rrole 

It is also possible to generically (pre)define two roles for any arbitrary binary relation 
as follows : 



leftRole : {p ^ c) X c — >Pp 
rightRole : {p ^ c) x p — >Pc 

VR-.p^c-^vc-.c* leftRole{R, vc) = 7?~(|{vc}D 
'iR:p^c;vp:p» rightRole{R, vp) = r({vp}^ 



These definitions illustrate the amazing power of Z for defining builtin syntax exten- 
sions, as well as the richness of the relational operator toolkit of Z, later useful for 
specifying object constraints. It must be noted that from our viewpoint, Z offers a clear 
advantage over other object oriented |[T6l . or terminological Ianguagesll3l l27l for object 
oriented constraints wrt. a potential broad acceptance, since relation definition is not 
role centered, but relations, functions and roles can freely coexist. 

3.3 composition, aggregate relations 

Object modeling leads to a clear separation between two broad categories of relations. 
General relations are unconstrained, meaning that every tuple can be accepted, regard- 
less of the number of times an object appears on either side. For instance, in modeling 
a network of PCs and printers, any PC can view any number of printers (even though 
it may not see all of them), and any printer can be accessed by any number of PCs. No 
limitation stems from the nature of the relation itself. 

Other relations are more constrained. For instance, no PC can share its mainboard. 
This is an example of a composition relationship. To distinguish between both just 
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involves changing the type of the relation to make it a function of a special kind. If a 
relation stated between the composite type and the component type (in this sequence) 
is a composition one, it means that its relational inverse is an injective partial function 
(each component occurs in at most one composite). If no component can be left aside, 
the relational inverse is injective. Z provides various notations for constrained functions 
: injections start with an arrow i>-^, h->), surjections end with a double arrow (— », 
-i-»), partial functions have a bar in the middle (h->, -t-»), bijections are both injective 
and surjective (v-»), whereas unconstrained functions are denoted with a simple arrow 
( — >) and standard relations have two opposed arrows (<—>). 

uses : PC <— > Printer 
hasMainBoard : PC <— > MainBoard 

hasMainBoard"" € MainBoard h-> PC 

If components cannot be optional, the injection becomes non partial 

hasDVDWriter : PC DVDWriter 
hasDVDWriter- e DVDWriter ^ PC 

In the most constrained case, of a strict one to one relation between types, the relation 
becomes a bijection, which can be formulated as follows : 

I hasMainBoard : PC MainBoard 

More generally, any constraint can be stated upon a relation using general quantified 
formulas and all of Z's constructs. The distinction made in the UML between aggregate 
and standard relations is conceptual, and does not relate to constraints in our sense 
here. Aggregate relations models relations where a dynamic, not structural dependency 
exists among between objects. For instance, translating a paragraph in a text amounts 
to translating all its characters. 

3.4 multiplicities 

Relation multiplicities can be naturally stated as well. Object models often constrain 

for a given relation the number of related target objects for each source object. For 
instance, a PC has at most four memory units plugged (the # operator denotes a set 
cardinality). 

hasMemory : PC <— > Memory 

Mpc : PC • 4j={hasMemoryl\{pc}) ) < 4 

3.5 ordered relations 

Object models sometimes require that the tuple ordering is significant to a relation. For 
instance, should we model the relation between polygons and points, it is clear that we 
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need a list, not a set, of points to describe the Polygon. The concept available in Z to 
model this is the sequence. 

I builds : Polygon — > (acqPoint) 

To restrict the multiplicity in this case (for instance to describe all the pentagons) re- 
quires a little different work than before 

builds : Polygon — > (seqPoint) 

\/p : Polygon • ^builds = 5 

To ensure that an object does not occur twice or more in a sequence, we need to make 
the sequences injective: 

I builds : Polygon — > {iseqPoint) 

To decide that a Point in our example does not occur in the definition of two or mode 
different Polygons, we state : 

builds : Polygon — > {iseqPoint) 

Vpi,p2 : Polygon • items {builds(pi)) fl items {builds(p2)) — 

3.6 reified associations 

An important feature in object oriented modeling is the possibihty to attach extra in- 
formation to associations in the model. This added information is carried by an associ- 
ation class, which can be a standard class (i.e. with a name) or be anonymous. We can 
however assume the existence of a name since the association class for a given relation 
R can be named automatically (e.g. as R-DATA)). 

We thus expect the association class used in coordination with a given relation to 
be properly defined as a class according to the former framework. If we return to the 
worksFor example, we see that an obvious related information can be the salary (the 
salary can be different if a person works for two different companies, hence it cannot 
be an information carried by the Person itself). 

class — Enrolmentlnfo : concrete 

salary : N 

a > MINJSALARY; 



This definition yields as usual two schemas : ClassDefEnrolmentlnfo, ClassSpecEnrolmentlnfo, 
and two sets : instance {ClassEnrolmentlnfo) and Enrolmentlnfo. The latter is the type 
associated with objects built as members of Enrolmentlnfo itself or subclasses. Binding 
the enrolment information to the worksFor relation is the fact of a function from the 
worksFor tuples to the type Enrolmentlnfo. 

I mapEnrolmentlnfo : worksFor — > Enrolmentlnfo 

If the attached information is optional, the function is partial : 

I mapOptionalEnrolmentlnfo : worksFor -h- Enrolmentlnfo 
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4 Constraints 

4.1 structural constraints : example 

Constrained object oriented problems abound with constraints spanning across the ob- 
ject structure, traversing relations to gather information. The Z notation again offers 
many possible ways to state such constraints. Lets study an example, classical in the 
configuration community. The model describes all valid PC's, composed from standard 
components, in a simplified form. 

We declare the following classes : PC, PowerSupply, MainBoard, Monitor, Processor. 
Except for PowerSupply and PC all the classes inherit an abstraction called Device, 
with an attribute called powerUsed. PowerSupply has an attribute called power. We 
also have the relations PC-PowerSupply, PC-MainBoard, PC-Monitor and MainBoard-Processor. 
The shortcut definitions for these classes are : 

class — Device : abstract 

powerUsed : N 



class — PC : concrete 



class — PowerSupply : concrete 

power : N 



class — MainBoard : concrete 

—inherit : Device 



class — Processor : concrete 

—inherit : Device 



class — Monitor : concrete 

—inherit : Device 



We also declare the composition relations (assuming default role names) PCJPower Supply, 
PC-MainBoard, PC-Monitor and MainBoard-Processor^ 

PC— PowerSupply : PC <— > PowerSupply 
PC-Monitor : PC ^ Monitor 
PC— MainBoard : PC <— > MainBoard 
MainBoard— Processor : MainBoard <— > Processor 

PC— PowerSupply"^ G PowerSupply > — > PC 
PC-Monitor"" G Monitor ^ PC 
PC— MainBoard"" G MainBoard > — > PC 
MainBoard-Processor"" G Processor ^ MainBoard 

^we intentionally continue to read the relations from composite to components to emphasize the fact that 
composition is a constraint 
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Now, we wish to state the constraint that the total power deHvered by a PowerSupply 
must exceed the total power demand by all the devices in the PC. This is a classical 
example of structural constraint. To achieve this, we must define several utilities. 

4.2 structural constraints utilities 

We need several intermediate definitions useful to declare constraints. For instance, 
some integer arithmetic functions generalize to the case of bags of natural numbers, or 
numerals. Some of the properties of object systems require to gather some information 
over the structure (like the price, or the power used by electrical units for instance). 
Such information is best represented in bags, which allow repeated occurrences of the 
same value. Given a bag, we may ask for its min, max, or sum for instance. We detail 
these three function, which may serve as a template for possible others. 

In the rest of the sub section, we also provide a function that can be used to generate 
a sequence from a set. Since converting from bags to sets is immediate, and converting 
from sequences to bags is predefined by the function items, this allows to convert any 
structure type into any other. 

computing the min and max over a bag of naturals 



bagmin : 


bag N ^ N 




bagmax : 


bag N ^ N 




\fb : bag 


N • bagmin{b) 


= min {domb) 


Vfo : bag 


N • bagmax (b) 


= max (dom b) 



summing up the elements in a bag of naturals 

bagsum : bag M — >N 

bagsum(0) = 

\/b : bagN I (dom^) • 

(let X == bagmin{b) • bagsum{b) = b{x) *x + bagsum{b \ {(x, b{x))})) 

To understand this definition of bagsum, it suffices to recall that a bag is a partial 
function from a set to strictly positive integers (the number of times an element is 
counted). 

conversion functions 

We define a conversion function from totally ordered finite sets to sequences. This 
function asSeq converts a finite set to a sequence, which may be further converted to a 
bag using the items operator on sequences. This provides full possibilities of converting 
from a container type to another. We need a function to select a member from a set. 
This is possible deterministically for totally ordered sets, as are N or the set of rational 
numbers. We present the specification of the conversion function asSeq in the case of 
natural numbers. This gives a template for the definition of similar conversion functions 
applying to totally ordered sets of non integral elements. 
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asSeq : F N — > seq N 

asSeq{0) = () 

V5 : N • (let x == {maxS) • asSeq{S) = asSeq{S \ {x}) U {#5 i-^ x}) 
building a bag of attribute values 

Together with any attribute, we know that we can specify an accessor function which, 
given an object reference will return the attribute value held by the object structure 
mapped to We have established the convention of naming getXyz the accessor func- 
tion for attribute xyz. We generaUze this concept to sets of object references. We want, 
given a set of object references, to build the bag of corresponding attribute values. In 
our example, we expect the following accessor functions to be implicitly defined from 
the class declaration as follows : 

getPower : PowerSupply — > N 

Vj : Device • getPower{i) = {jiv : {s : ClassSpecPowerSupply \ s.i = i • s.power} • v) 

getPowerUsed : Device — > N 

V i : Device • getPowerUsed{i) = 

(/iv : {s : ClassSpecMonitor \ s.i = i • s.powerUsed}U 

{s : ClassSpecProcessor \ s.i = i • s.powerUsed}U 

{s : ClassSpecMainBoard \ s.i = i • s.powerUsed } • v) 

We further make the assumption that the set ObjectReference to be totally ordered^, 
which allows to define a function called pickFirst yielding the first element of any 
finite set of ObjectReferences : 

I pickFirst : F ObjectReference — > ObjectReference 

From these accessors and the function first, we may form their generahzed counterpart 
as (we use bag as a prefix to form the function names) : 

bagPower : F PowerSupply — > bag N 
bagPower{0) = 

V J : F-^ PowerSupply • (let x pickFirst{d) • 

bagPower{d) — {bagPower(d \ {x}) W {{getPower{x) i-^ 1}))) 

In the same spirit, we could define bagPowerUsed by simply replacing PowerSupply 
by Device, and getPower by getPowerUsed in the previous statement. 

bagPowerUsed : F Device — > bag N 



^This is not unrealistic, since object references generally will be interpreted as integers (machine pointers 
are integers). 
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As in the case of association roles, it is possible to elaborate a generic definition for 
these : 

bagOf : [ObjectReference — >X) — > (F ObjectReference — > bagX) 

V/ : ObjectReference bagOf(f){0) = |1 

V/ : ObjectReference — > X • 

Md : F;^(dom/) • (let x == pickFirst{d) • 
bagOf(f){d) = {bagOf(f){d \ {x}) W {{fix) ^ 1}))) 



The function bagOf hence maps every function from ObjectReference to X to a func- 
tion from sets of ObjectReference to bags of X. 

4.3 inter relation constraints 

The basic constraint existing between relations is the subset constraint. A simple ex- 
ample is given by the two relations worksFor and manages, between the types Person 
and Company. The manager obviously works for the company, which is expressed as 
manages C worksfor. Hence the proper declaration for these relations becomes : 

worksFor : Person <— > Company 
manages : Person <— > Company 

manages C worksFor 

4.4 structural constraints 

We wish to state the constraint that the total power delivered by the power supply 
suffices to feed all of the PC's devices. This can be stated as follows : 

Wp:PC» 

(let R == PC-Monitor U PC-MainBoard U MainBoard-Processor • 

bagsum {bagOf{getPower) (PC—PowerSupplyl\{p } D ) ) > 
bagsum{bagOf {getPowerUsed){R^ \{p}\) n Device))) 

where /?+ denotes the transitive closure of the relation R, obtained as the union of three 
relations, and /?"'"(|{p}D denotes the relational image of p, the PC composite, by R^, 
hence the component objects of p, at any structural level. 

4.5 notational shortcuts for relations and roles 

Most often, specifications require to make the structure traversal more explicit. To 
illustrate the possibilities offered by Z in that respect, we assume that all previous 
relations have roles named using a standard prefix "the" followed by the distant class 
name (we use no s at the end, even when there can be several), as e.g. : 

I theMonitor : F PC — > F Monitor 
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■■[X] 

_ ^ _ : F ObjectReference x {ObjectReference — > X) — > ha,gX 
_ ^ _ : F ObjectReference x {ObjectReference — > X) — > X 
_ • _ : F ObjectReference x (F ObjectReference — >¥ X) — >¥X 
_ _ : ObjectReference x (F ObjectReference — > ¥ X) — > ¥ X 



\/ s :¥ ObjectReference] r : ObjectReference — > X • s r = bagOf{r)(s) 

y s : ¥ ObjectReference] r : ObjectReference — >X • s ^ r = {fit : bagOf{r){s) • first t) 

y s : ¥ ObjectReference; r : ¥ ObjectReference — > ¥ X • s ■ r — r{s) 

Vo : ObjectReference] r : ¥ ObjectReference — > ¥ X • o r — r{{o}) 



\/p:PC» 

p thePowerSupply getPower > 

p theMonitor getPowerUsed+ 

p theMainBoard getPowerUsed+ 

bagsum{p theMainBoard ■ theProcessor — > getPowerUsed) 



5 An AI Example 

We wish to illustrate the use of the specification utilities and frameworks presented 
so far with a simple yet very general artificial intelligence problem. ||9l defines the 
problem of analyzing both the syntax and semantic of a context free language using a 
constraint object system, the language chosen is the archetypal language C ~ a" b" 
consisting in sequences of a's followed by the same number of b's. aaabbb G C, but 
abbb ^ C. f9\ proposes the object model and constraints described below to represent 
valid sentences of C together with their semantic. The object model is illustrated in fig- 
ure|2] The program used to solve the problem is Hog JConfigurator, an object oriented 
configurator. Given an input made of a sequence of words, some of them not being 
classified as a's or b's, the system can generate all the valid word sequences compati- 
ble with that input together with the correct syntax structure. The system works equally 
well when chunks of syntactical structure, or elements of the semantic, are fed in. 

In other words, the system produces the following results (where inputs and outputs 
are sequences {stringy syntax tree, semantic)) (we use the dot character "." do denote 
an unknown word (a, or b), and the character "?" to denote an unknown : 

{aaabbb,'!,'!) ^ {aaabbb,S{SA,S{SA,S{SA,null,SB),SB),SB),5) 
{abbb, ?, ?) false 

{.a.b,?,?) ^ {aabb,S{SA,S{SA,null,SB),SB),2) 
(?,?,2) ^ {aabb,S{SA,S{SA,null,SB),SB),2) 

We propose here a rigorous, type checked specification of the object model and 
its constraints, that illustrate the power of the method. We start with the definition 
of several classes. Word* is an abstraction for SA and SB (representing a and b). Cat 

^Following the terminology of natural language theories, we use "phrase" to denote a valid sentence for 
the grammar, called a "word" or a "string" in formal language theory 
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Phrase 



Semantic 




Figure 2: An object model for the a"b" parsing problem 



is an abstraction for both Word and S. S is the only syntactic construct, made of an 
SA, an optional enclosed S, and an SB in that order. The Phrase consists of a list of 
Word, a syntax S, and a Semantic. The semantic chosen is as simple as the example : it 
describes the count of a's and b's in the sentence. 

, class — Phrase : concrete 



class — Cat : abstract 

begin : N 
end : N 



class ~ Word : abstract 

—inherit : Cat 



class — S : concrete 

—inherit : Cat 



class — &4 : concrete 

—inherit : Word 
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class — SB : concrete 

—inherit : Word 



class — Semantic : concrete 

n : N 



Several relations exist in this problem. They can be described very naturally by their 
most used roles. Whenever the opposite role is needed, the inverse of the relation 
can be computed. Each phrase maps to a unique first word. Each word maps to a 
unique phrase. Each word has an optional next word. Each phrase bijectively maps to 
a semantic. It also maps to a unique syntax S. Each SA (and SB) bijectively maps to 
an S. Each S has an optional enclosed S (we use a partial injection here). Each S is in 
a one to one with its semantic. We also know that the first word is a member of the 
phrase words. All these elements can be formulated as : 

firstWord : Phrase — > Word 
phrase : Word — > Phrase 
next : Word H-> Word 
phraseSemantic : Phrase Semantic 
phraseSyntax : Phrase — > S 
SASyntax : SAy^ S 
SBSyntax : SB S 
subSyntax : Sy+^ S 
semantic : S Semantic 

firstWord C phrase'" 

In some constraints below, we expect the following functions to be impUcitly defined : 

theSA ■.¥S^¥SA 
theSB : F 5 ^ F 
theSubS : F 5 ^ F 5 
thePhraseSyntax : ¥ Phrase — > ¥ S 

The following accessor functions are also implicitly defined : 

getBegin : Cat — > N 
getEnd -.Cat^N 
getN : Semantic — > N 

Using these definitions, we may formulate the following axioms, necessarily veri- 
fied by the object system. Of course, some or all of these axioms must be implemented 
as constraints in a working system. 
The length of words is one 

Vw : Word • getBegin{w) + 1 = getEnd{w) 
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The start position of the first word in a phrase is 

Vp : Phrase • getBegin(firstWord{p)) = 
The first word in a phrase is the SA of its syntax (S) 

Vp : Phrase • firstWord{p) = SASyntax'" {phraseSyntax(p)) 
Consecutive words have corresponding end/begin 

Vw : domnext • getEnd{w) = getBegin{next{w)) 
All a's are located left of all b's 

Va : SA; b : SB • getBegin{a) < getBegin{b) 

The beginning of an S is the beginning of its SA (and respectively with SB's and 
"ends"). 

ys:S» getBegin{s) = s theSA — ^ getBegin 
ys:S» getEnd{s) = s theSB — ^ getEnd 

The enclosed S is between the SA and the SB. 

: dom subSyntax • getBegin{s) < s theSubS getBegin 
Vs : dom subSyntax • getEnd{s) > s theSubS getEnd 

The end position of the SA plus the length of the enclosed S equals the start position 
of the SB 

V s : dom subSyntax • 

s theSA — ^ getEnd + s theSubS — ^ getEnd — s theSubS — ^ getBegin = 

s theSB getBegin 

y s : S \ s ^ dom subSyntax • s ^ theSA getEnd = s theSB getBegin 

The semantic of a phrase is the semantic of its syntax 

V/? : Phrase • phraseSemantic(p) = semantic(phraseSyntax{p)) 

The "value" of the semantic of an "S" is the integer division of the its length by two 

Vs : 5 • getN{semantic{s)) = {getEnd{s) — getBegin(s)) div 2 
Vs : 5 • getN{semantic{s)) mod 2 = 

Not all these axioms are independent of course. However, they formally describe all 
the vaUd object configurations that are instances, or solutions, of this object model. 
Provided the class definitions are properly expanded, or this expansion is simulated, 
all the constraints can be fully type checked by a Z type checker. Furthermore, these 
axioms can be input to a theorem prover, with the possibility of generating automatic 
or user assisted proofs for conjectures about the properties of the problem, or proofs 
that some constraints are mutually incompatible. 

The same specification may also be converted automatically to a vaUd input for any 
practical configurator or object constraint program. 
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5.1 Formal proofs 

All object models so specified naturally allow formal proofs to be made about the 
axiom set. Essential in that respect are redundancy proofs. In constraint systems, any 
axiom that can provably be inferred from the rest of the axioms can be safely ignored by 
an implementation, which hence remains correct. Also, redundant axioms can be added 
when their implementation as a constraint has a better propagation efficiency than the 
axioms it can be derived from. In this case, redundancy ensures that the resulting 
system remains complete. 

We illustrate the possibility to establish formal proofs for our example. : S • 
getN{semantic{s)) mod 2 = can be proved by induction on the height of the syntacti- 
cal structure (or the value of the semantic "n"). A sequent proof for height 1 (ie. for an 
"S" having no enclosed "S", or in other words for the "S" corresponding to the central 
"AB") is : 

M s : S \ s ^ Aom subSyntax • s theSA — ^ getEnd = s theSB getBegin 
V ir : Word • gelBegiii{\v) + 1 = gel End (\v) 

: S \ s ^ domsubSyntax • getEnd{s) — getBegin{s) = 2 

\/ s : S \ s ^ domsubSyntax • getEnd{s) — getBegin{s) = 2 
Vs : S • getN{semantic{s)) = {getEnd{s) — getBegin{s)) div 2 

M s : S \ s ^ domsubSyntax • getN {semantic {s)) mod 2 = 

Now, we can formally prove that if the induction hypothesis is true for height n, it holds 
for height « + 1, hence for all n. We can first establish as a lemma that the length of an 

5 equals 2 plus that of its subSyntax : 

Vi : domsubSyntax • 

s theSA getEnd + s theSubS getEnd — s theSubS getBegin 

s -w theSB — ^ getBegin 
Vw : Word • getBeginiyv) + 1 = getEnd{w) 

y s : domsubSyntax • getEnd{s) — getBegin{s) = 

2 + s ^ theSubS getEnd — s theSubS getBegin 

which makes the proof of the induction step obvious. 

6 Conclusion 

We have presented the entire specification of an object oriented constraint system, 
which can be used to document and exchange constrained object models. We used 
Z as an underlying formal system which offers many advantages: 

• Z has very simple and clean first order semantics. 

• as a relational language, Z offers the richest possible ways of reasoning about 
relations, which is an essential aspect of constrained object systems. 
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• Z is freely extensible by introducing new operators, always backed by rigorous 
axiomatic definitions. This allows to attain the flexibility and readability of ex- 
isting object oriented approaches. 

• the Z language comes with a freely available type checker /uzz, that allows to 
control both the syntax and the type conformance of specifications (this article is 
fully type checked using/uzz). 

Our goal was to capture as much of object oriented modeling as possible, using as 
a basis the widely accepted standard UML, while avoiding to produce a new avatar 
of an object oriented language. We also rejected the idea of using an existing one, 
since all existing formal object languages have their pros and their cons, which might 
have interfered with the general objective of producing a tool for communicating and 
discussing constrained object systems. Even though some of our choices may still 
be discussed, this can be made formally. Furthermore, the Z language being formally 
extensible at will, all the proposed generic operators can be viewed as a template, rather 
than a rule. 
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